Most float functions are marked `#[inline]` so any float symbols used by
these functions only need to be provided if the function itself is used.
RFL recently noticed that `next_up`, `next_down`, and `midpoint` for
`f32` and `f64` are not inline, which causes linker errors when building
with certain configurations [1].

Add the missing attributes so the symbols should no longer be required.

Cc: Gary Guo <[email protected]>
Reported-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/all/[email protected]/ [1]

…k-nonnull-alignoffset-update, r=Amanieu

Update NonNull::align_offset quarantees

This PR proposes to update [`NonNull::align_offset`](https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.align_offset) guarantees, which should to be matched with [`ptr::align_offset`](https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.align_offset-1)
(as `NonNull::align_offset` delegates to `ptr::align_offset`).

[PR rust-lang#121201](rust-lang#121201) updated only `ptr::align_offset` docs.

…ir, r=davidtwco

Make `validate_mir` ensure the final MIR for all bodies

A lot of the crashes tests use `-Zpolymorphize` or `-Zdump-mir` for their side effect of computing the `optimized_mir` for all bodies, which will uncover bugs with late MIR passes like the inliner. I don't like having all these tests depend on `-Zpolymorphize` (or other hacky ways) for no reason, so this PR extends the `-Zvalidate-mir` flag to ensure `optimized_mir`/`mir_for_ctfe` for all body owners during the analysis phase.

Two thoughts:
1. This could be moved later in the compilation pipeline I guess? I don't really think it matters, though.
1. This could alternatively be expressed using a new flag, though I don't necessarily see much value in separating these.

For example, rust-lang#128171 could have used this flag, in the `tests/ui/polymorphization/inline-incorrect-early-bound.rs`.

r? mir

Add regression test

Fixes rust-lang#125873

Mark `{f32,f64}::{next_up,next_down,midpoint}` inline

Most float functions are marked `#[inline]` so any float symbols used by these functions only need to be provided if the function itself is used. RFL recently noticed that `next_up`, `next_down`, and `midpoint` for `f32` and `f64` are not inline, which causes linker errors when building with certain configurations <https://lore.kernel.org/all/[email protected]/>.

Add the missing attributes so the symbols should no longer be required.

… r=jieyouxu

Update E0517 message to reflect RFC 2195.

E0517 occurs when a `#[repr(..)]` attribute is placed on an unsupported item. Currently, the explanation of the error implies that `#[repr(u*/i*)]` cannot be placed on fieldful enums, which is no longer the case since [RFC 2195](rust-lang/rfcs#2195) was [stabilized](rust-lang#60553), which allows placing `#[repr(u*/i*)]` and/or `#[repr(C)]` on fieldful enums to produce a defined layout.

This PR doesn't (currently) add a description of the semantics of placing `#[repr(u*/i*)]` on a fieldful enum to the error explanation, it just removes the claims/implications that it is not allowed.

…petrochenkov

rm `declared_features` field in resolver

r? ``@petrochenkov``

…s, r=compiler-errors

Only suggest `#[allow]` for `--warn` and `--deny` lint level flags

`--force-warn` and `--forbid` cannot be overridden